There are a number of applications requiring accurate frequency and/or time synchronization references in order to properly operate, for example mobile technologies such as Global System for Mobile Communications (GSM), Wideband Code Division Multiple Access (W-CDMA) and in the future Long Term Evolution (LTE). In case of frequency synchronization the traditional solution is to get synchronization from a synchronous stream of data, as for instance in case of Time-Division Multiplexed (TDM) based networks, but the migration of networks from TDM to packet-based technologies (such as Ethernet) requires a different approach.
One solution is to use a packet based method, where the timing is carried across a packet network by sending packets containing timestamp information. The timestamps are generated by a master (server) that has access to an accurate reference, such as Global Positioning System (GPS).
Each receiving system can run an algorithm that recovers the timing based on adaptive clock recovery methods, e.g. by comparing the local timing with the inter-arrival times of the packets (see ITU-T G.8261). The accuracy of the recovered clock is therefore affected by variable delays in the network, and one of the key requirements of the algorithm is to filter out the packet delay variation.
When time synchronization is requested, a two-way timing protocol is required (e.g. Network Time Protocol (NTP) or Precision Time Protocol (PTP)). The transfer delay from master to slave is calculated. One fundamental assumption with this approach is that the delay from master to slave and from slave to master shall be identical. This means that any asymmetry in the network would significantly impact the performance of the delivered time synchronization reference.
As an example, the scheme shown in FIG. 1 relates to the time distribution via the PTP protocol (IEEE1588). Similar discussion applies with other protocols such as NTP. The message exchange pattern is:                The master sends a Sync message to the slave and notes the time, t1, at which it was sent.        The slave receives the Sync message and notes the time of reception, t2.        The master conveys to the slave the timestamp t1 by:                    Embedding the timestamp t1 in the Sync message. This requires some sort of hardware processing for highest accuracy and precision, or            Embedding the timestamp t1 in a Follow_Up message.                        The slave sends a Delay_Req message to the master and notes the time, t3, at which it was sent.        The master receives the Delay_Req message and notes the time of reception, t4.        The master conveys to the slave the timestamp t4 by embedding it in a Delay_Resp message.        
At the conclusion of this exchange of messages, the slave possesses all four timestamps. These timestamps may be used to compute the offset of the slave's clock with respect to the master and the mean propagation time of messages between the two clocks, which in FIG. 1 is the mean of t-ms and t-sm. The slave shall synchronize to its master via the minimization of the <offsetFromMaster> value computed by the slave. The time error between a slave and master ordinary or boundary clock (<offsetFromMaster>) is defined as:                <offsetFromMaster>)=<Time on the slave clock>−<Time on the master clock> where all times are measured at the same instant.In particular, the <offsetFromMaster> value shall be computed by the slave as follows:        
If a Follow_Up message will not be received, then                <offsetFromMaster>=(t2−t1)−<meanPathDelay>−correctionField of Sync message.        
If a Follow_Up message will be received, then                <offsetFromMaster>=(t2−t1)−<meanPathDelay>−correctionField of Sync message−correctionField of Follow_Up messagewhere correction field of Sync message relates to the support in the transport network (i.e. Transparent Clocks adding information on the latency for the packet crossing the transport network element).        
The nominal value of the <meanPathDelay> is computed as<meanPathDelay>=[(t2−t1)+(t4−t3)]/2=[(t2−t3)+(t4−t1)]/2
The scheme is slightly different in case of Peer-to-Peer Transparent clocks where the Path delay is calculated at each hop and included in the correction field of the sync message (or Follow-up message in case of 2-steps clock) in addition to the latency.
From the above description it can be seen that the computation of offset and propagation time assumes that the master-to-slave and slave-to-master propagation times are equal. Any asymmetry in propagation time introduces an error in the computed value of the clock offset. The computed mean propagation time differs from the actual propagation times due to the asymmetry.
If the delay asymmetry of the path connected to the ingress port is known, the corrections can be made as specified by the PTP protocol.
In particular IEEE 1588 defines the attribute “delayAsymmetry” as follows for t-ms and t-sm:tms=<meanPathDelay>+delayAsymmetrytsm=<meanPathDelay>−delayAsymmetry
In other words, delayAsymmetry is defined to be positive when the master-to-slave or responder-to requestor propagation time is longer than the slave-to-master or requestor-to-responder propagation time.
In order to handle the packet delay variation and the asymmetries in the network the “Boundary Clock” or “Transparent Clock” functions have been specified by IEEE 1588.
The IEEE 1588 transparent clock is a function that provides a means of measuring the delay that has been added by the network element and of measuring the delays on links connected to the network element. The end-equipment can use this information to recover the time reference.
The boundary clock, by contrast, terminates and regenerates timestamp packets. While any asymmetry in the node is effectively removed by means of the HW timestamping at the ingress and egress ports, still asymmetries may be present in the links connecting two nodes.
This may happen in case of forward and reverse traffic (and therefore PTP flow) in the same fibre but over different wavelength (e.g. WDM-PON) or in case of forward and reverse traffic in two different fibres (and using the same wavelength), therefore with different transmission characteristics and different length.
The accuracy of phase/time synchronization required by mobile networks is typically in the order of microseconds. This implies that the requirements for technologies such as IEEE 1588v2 to provide precise phase/time over transport networks require that the handling of any source for asymmetry is controlled at the ns level.
In order to remove the asymmetries in the links, currently the only solution is to manually calibrate the links. If the delay asymmetry of the path connected to the ingress port is known, the corrections can be made as specified by the PTP protocol.
This must be performed node-by-node and can be an extremely costly and time consuming process. Moreover, at any change in the network (e.g. adding transmission equipments) the compensation has to be updated. This can be a too complex and costly task creating a significant obstacle in the deployment of the IEEE1588 technology.